# !/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
===========================
@Time : 2022/7/9 0009 18:37
@Author : 测试开发工程师
@File : 5. 电商系统压测实战.py
@Software: PyCharm
============================
"""


"""
有效的性能测试能给研发，运维团队提供有效的 容量规划能力，系统风险识别，系统瓶颈识别，性能调优指导。保障尽量避免以上问题发生
压力测试 ->   Ngnix   ->   应用1，应用2  ->   Redis  ->   DB

一：性能需求指标
    时间指标  -  响应耗时（500ms）   - （2/5/8已经淘汰）
    容量指标  -  支持多少在线用户并发，数据量规模
    资源利用率指标（运维） -  CPU 内存 网络  磁盘
二： 性能模型
    业务模型   -  用户的真实流程（事务） 链路场景压测
    监控模型  
三： 性能方案：
    测试环境  : 线上环境  线下环境
    测试数据  -  某种比例的（用户数据。订单数据，商品数据）
    测试模型
    性能指标：   
        TPS（吞吐量） : 每秒事务处理能力
        RT ： 响应时间
        资源利用率 ： CPU 、 磁盘 、内存 、 硬盘读写
        时延 : 时延是指一个报文或者分组从一个网络的一段传送到另一个端所需要的时间。包括 发送时延、传播时延、处理时延、排队时延
        QPS : 每秒请求数  QPS = req/sec = 请求数/秒，代表服务器的性能最大吞吐能力
        错误率
    压力策略  -   递增（容量和调优）
    准入准出  -  系统做什么样的适配，满足支持线上用户
    进度风险
四： 性能监控  -  日常关注客户端
    系统架构
    系统监控
    中间件监控
    缓存监控
    队列监控
    负载均衡监控
    熔断限流
    链路监控
五： 性能场景执行
    基准性能
    容量性能
    稳定性场景
六： 性能结果/报告
    场景结果整理
    监控结果整理
    性能整体分析
    性能结论    -   重点 
    优化建议
    运维建议
 
PV(访问量)： 即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
UV(独立访客)：即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次



 一：需求分析与测试设计（性能需求目标 + 业务模型拆解）   产品 TPS , PV/UV(天) -> 转化成 小时/分钟
    1. 根据具体的性能测试要求，确定测试类型以及压测的模块（web/mysql/redis/系统整体）
    2. 前期要与相关人员充分沟通，初步确定压测方案及具体性能指标
    3. QA完成性能测试设计后，需产出测试方案文档发送邮件到项目组，并且再次与相关人员沟通（或者组织性能测试评审），确认是否满足需求
 二：环境设计与搭建
 三：测试数据准备（基于模型的数据准备）
    1. 接口请求的参数：自己构造（抓包）/日志获取（Nignx）/上下关联（参数传递）
    2. 数据表的数据填充  - 链路（web/mysql/redis/系统整体）
    3. 如果是多接口，则需结合业务场景设计请求比例
 四：性能指标预期（性能需求目标）
    1. 每秒请求数（QPS）
    2. 请求响应时间（最大，最小，平均）
    3. 错误率
    4. 机器性能： cpu, idle 30%,memory 无剧烈抖动或者飙升
    5. 压测过程中接口功能是否正常
    
发压工具准备：
    jmeter 工具准备：
        1.集成包，解压即可使用， windows linux 通用（依赖java环境）
        2. jmx 脚本为xml文件，win,linux环境均可直接运行
        3. 多线程并发
        4. 运行完脚本会生成jtl 日志，可在win环境界面工具查看，统计
    脚本的编写：
        1. http 请求
        2. 其他
    命令：
        启压： ./jmeter -n -t hb.jmx -l hb.jtl

 五：发压工具配置及脚本编写（压力策略）  JMeter
        压测过程说明
        1. 测试前环境检查：记录机器参数
        2. 起压：根据被压情况，调节并发量到合适的情况
        3. 查看记录各项性能指标
            nginx 日志查看每秒请求数
            查看 nginx 错误请求
            查看机器参数： cpu idle,mem等
            查看 db,cache等数据是否正常写入
            访问接口，查看功能是否正常
结果分析和测试报告：
    根据测试过程中记录的各项参数，结合压测工具产生的日志，对测试结果进行分析，并产出测试报告
    测试完成后，及时与相关人员沟通，确认是否满足需求
    发送测试报告邮件
       
压测工具 ：JMeter
    压测场景 ： 单接口/复杂事务   -> JMeter 场景构造
    压力需求 ： <1000 QTS or 万级以上  -> JMeter 分布式支持
    是否周期性 ： JMeter Jmx 场景文件，数据驱动，结果落地
    二次开发需求 ：Jmeter 开源插件化思想，支持 Thriff
    Dubbo 多种协议。可快速平台化
    问题支持 ： JMeter 开放社区，广泛使用
            
 六：测试过程（预计的前置准备过程，和压测时间点规划）  - 拐点（两个：最优的点，系统风险的级值）：  横轴：并发用户数。纵轴： 资源利用率，吞吐量，响应耗时（雪崩）
 七：结果分析与测试报告  - 对测试结果进行分析，并产出测试结果
    
场景：基准性能测试 
    1. 新系统上线 -  容量测试   5w用户  响应时间小于200ms
    2. 重构后 - 性能调优专项，和基线性能版本对比，性能不下降
    
抖动飙升：
    mysql 慢查询过多，拖累整个请求的性能指标。
    导致：1. mysql开始报警（cpu高，慢查询多，主送延迟）  
    2. 被测系统指标 ： 1. 所有耗时开始增加 2. 堆列开始堆积
    
被测系统 ：mall 前台系统   http://47.93.32.161:8085/swagger-ui.html
    整体服务存储分为： -   在压测过程中，对不同方式存储需不同关注
        Mysql : 关系型数据存储，商品，订单等数据
        Redis : 缓存，部分存储。例如：验证码
        MongoDB : 例如用户关注品牌等存储

"""